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ESMTP and LMTP Transmission Types Registration 
Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
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Abstract 


This registers seven new mail transmission types (ESMTPA, ESMTPS, 
ESMTPSA, LMTP, LMTPA, LMTPS, LMTPSA) for use in the "with" clause of 
a Received header in an Internet message. 


1. IANA Considerations 


As directed by SMTP [2], IANA maintains a registry [7] of "WITH 

protocol types" for use in the "with" clause of the Received header 
in an Internet message. This registry presently includes SMTP [6], 
and ESMTP [2]. This specification updates the registry as follows: 


o The new keyword "ESMTPA" indicates the use of ESMTP when the SMTP 
AUTH [3] extension is also used and authentication is successfully 
achieved. 


o The new keyword "ESMTPS" indicates the use of ESMTP when STARTTLS 
[1] is also successfully negotiated to provide a strong transport 
encryption layer. 

o The new keyword "ESMTPSA" indicates the use of ESMTP when both 
STARTTLS and SMTP AUTH are successfully negotiated (the 
combination of ESMTPS and ESMTPA). 


o The new keyword "LMTP" indicates the use of LMTP [4]. 
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o The new keyword "LMTPA" indicates the use of LMTP when the SMTP 
AUTH extension is also used and authentication is successfully 
achieved. 


o The new keyword "LMTPS" indicates the use of LMTP when STARTTLS is 
also successfully negotiated to provide a strong transport 
encryption layer. 


o The new keyword "LMTPSA" indicates the use of LMTP when both 
STARTTLS and SMTP AUTH are successfully negotiated (the 
combination of LSMTPS and LSMTPA). 


o The references for the ESMTP and SMTP entries in the registry 
should be updated to the latest specification [2] since both RFC 
821 and RFC 1869 [5] are obsoleted by RFC 2821. 


2. Implementation Experience 


The ESMTPA, ESMTPS and ESMTPSA keywords have been implemented in 
deployed email server software for several years and no problems have 
been reported with their use. 


3. Security Considerations 


Use of these additional keywords provides trace information to 
indicate when various high-level security framing protocols are used 
for hop-to-hop transport of email without exposing details of the 
specifics of the security mechanism. This trace information provides 
an informal way to track the deployment of these mechanisms on the 
Internet and can assist after-the-fact diagnosis of email abuse. 


These keywords are not normally protected in transport which means 
they can be modified by an active attacker. They also do not 
indicate the specifics of the mechanism used, and therefore do not 
provide any real-world security assurance. They should not be used 
for mail filtering or relaying decisions except in very controlled 
environments. As they are both cryptic and hidden in trace headers 
used primarily to diagnose email problems, it is not expected they 
will mislead end users with a false sense of security. Information 
with a higher degree of reliability can be obtained by correlating 
the Received headers with the logs of the various Mail Transfer 
Agents through which the message passed. 


The trace information provided by these keywords and other parts of 
the Received header provide a significant benefit when doing after- 
the-fact diagnosis of email abuse or problems. Unfortunately, some 
people in a misguided attempt to hide information about their 

internal servers will strip Received headers of useful information 
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and reduce their ability to correct security abuses after they 
happen. The result of such misguided efforts is usually a reduction 
of the overall security of the systems. 
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Full Copyright Statement 
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to the rights, licenses and restrictions contained in BCP 78, and 
except as set forth therein, the authors retain all their rights. 


This document and the information contained herein are provided on an 
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Intellectual Property 
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on the procedures with respect to rights in RFC documents can be 
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